app/composables/npm/useUserPackages.ts (1)

113-113: 🚀 Performance & Scalability | 🔵 Trivial

Correct fix, but note the SSR/SEO trade-off.

Disabling server fetch here fully resolves the hydration mismatch, but it also means the ~[username] package list is no longer present in the server-rendered HTML — crawlers and no-JS clients will now see only a loading state until client-side fetch completes. This is consistent with the PR's stated approach, but as the linked issue notes, a longer-term fix of moving settings like searchProvider to cookies would let this stay SSR-rendered while still avoiding the mismatch.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/composables/npm/useUserPackages.ts` at line 113, The hydration mismatch
fix in useUserPackages is to disable the server-side fetch for the package
search state by keeping the default emptySearchResponse fallback and setting the
request to client-only. Update the useUserPackages composable so the search data
for ~[username] is fetched only on the client, which prevents SSR from rendering
a stale package list against client state. Keep this change localized to the
package list fetch/config in useUserPackages, and note that it intentionally
trades SSR content for hydration stability.

app/composables/useSettings.ts (1)

199-212: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Replace the manual mount flag with useMounted()

useMounted() is a drop-in replacement for the current shallowRef + onMounted pair and keeps the composable a bit cleaner.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/composables/useSettings.ts` around lines 199 - 212, `useSearchProvider`
currently uses a manual `shallowRef` plus `onMounted` to track mount state.
Replace that pattern with `useMounted()` in the same composable so
`searchProvider` continues to read `DEFAULT_SETTINGS.searchProvider` before
mount and `settings.value.searchProvider` after mount, while keeping the
existing computed getter/setter behavior unchanged.

app/composables/useSettings.ts (1)

198-207: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Good SSR-safe hydration fix; consider a brief comment.

Swapping the manual onMounted/shallowRef pattern for VueUse's useMounted() is correct and SSR-safe (it internally guards with getCurrentInstance() before registering the lifecycle hook), so the initial client render matches SSR output and avoids the hydration mismatch. Since the rationale isn't obvious from the code alone, a short comment would help future readers understand why mount-gating is needed here.

📝 Suggested comment

   const { settings } = useSettings()
+  // Fall back to the default value until mounted to avoid SSR/client hydration
+  // mismatches, since `settings` is sourced from localStorage (client-only).
   const isMounted = useMounted()

As per coding guidelines, "Add comments only to explain complex logic or non-obvious implementations."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/composables/useSettings.ts` around lines 198 - 207, The SSR-safe mount
gating in useSearchProvider is correct, but the intent is not obvious from the
computed getter that switches between settings.value.searchProvider and
DEFAULT_SETTINGS.searchProvider based on useMounted(). Add a short inline
comment near the mount check in useSearchProvider explaining that the mounted
guard keeps the initial SSR/client render aligned and avoids hydration mismatch,
so future readers understand why the value is deferred until mount.

Source: Coding guidelines

app/composables/npm/useUserPackages.ts (1)

12-14: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Duplicate, inconsistent typings for the same window global.

UserPackagesPrefetchWindow (lines 12-14) types the prefetch map as Record<string, Promise<RawNpmSearchResponse | null> | undefined>, while the inline type in onPrehydrate (lines 77-79) types the same global as Record<string, Promise<unknown> | undefined>. Since both are casts against the same runtime object, having two separate shapes risks silent drift if one is updated without the other. Consider extracting a single shared type/interface for __NPMX_USER_PACKAGES_PREFETCH__ and reusing it in both places.

♻️ Proposed consolidation

-type UserPackagesPrefetchWindow = Window & {
-  __NPMX_USER_PACKAGES_PREFETCH__?: Record<string, Promise<RawNpmSearchResponse | null> | undefined>
-}
+type NpmUserPackagesPrefetchMap = Record<string, Promise<RawNpmSearchResponse | null> | undefined>
+type UserPackagesPrefetchWindow = Window & {
+  __NPMX_USER_PACKAGES_PREFETCH__?: NpmUserPackagesPrefetchMap
+}

-    const prefetchWindow = window as typeof window & {
-      __NPMX_USER_PACKAGES_PREFETCH__?: Record<string, Promise<unknown> | undefined>
-    }
+    const prefetchWindow = window as UserPackagesPrefetchWindow
     const prefetches = (prefetchWindow.__NPMX_USER_PACKAGES_PREFETCH__ ||= {})

Also applies to: 77-79

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/composables/npm/useUserPackages.ts` around lines 12 - 14, There are two
conflicting type definitions for the same window global used by useUserPackages
and onPrehydrate, which can drift over time. Extract a single shared
type/interface for __NPMX_USER_PACKAGES_PREFETCH__ and reuse it in both the
UserPackagesPrefetchWindow declaration and the cast inside onPrehydrate. Keep
the promise value type consistent everywhere so both references describe the
same runtime object shape.